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TWO PHASE RESERVATIONS FOR PACKET 

NETWORKS 

BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to computer networks and, more specifically to the reserva- 
tion of bandwidth in computer networks* 

Background Information 

Computer networks typically comprise a plurality of interconnected entities. An 
entity may consist of any device, such as a computer or end station, that "sources" (i.e., 
transmits) or "sinks" (i.e., receives) datagrams (e.g., packets and/or frames). A common 
type of computer network is a local area network ("LAN") which typically refers to a 
privately owned network within a single building or campus. LANs typically employ a 
data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that 
defines the functions performed by the data link and physical layers of a communications 
architecture (i.e., a protocol stack). In many instances, several LANs may be intercon- 
nected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a 
wide area network ("WAN") or intranet that may span an entire country or continent. 

One or more intermediate network devices are often used to couple LANs to- 
gether and allow the corresponding entities to exchange information. For example, a 
bridge may be used to provide a "bridging" function between two or more LANs. Alter- 
natively, a switch may be utilized to provide a "switching" function for transferring in- 
formation between a plurality of LANs or end stations. Bridges and switches may oper- 
ate at various levels of the communication protocol stack. For example, a switch may 
operate at layer 2 which, in the Open Systems Interconnection (OSI) Reference Model, is 
called the data link layer and includes the Logical Link Control (LLC) and Media Access 
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Control (MAC) sub-layers. Data frames at the data link layer typically include a header 
containing the MAC address of the entity sourcing the message, referred to as the source 
address, and the MAC address of the entity to whom the message is being sent, referred 
to as the destination address. To perform the switching function, layer 2 switches exam- 
5 ine the MAC destination address of each data frame received on a source port. The frame 
is then switched onto the destination port(s) associated with that MAC destination ad- 
dress. 

Other network devices, commonly referred to as routers, may operate at higher 
communication layers, such as layer 3 of the OSI Reference Model, which in Transmis- 
10 sion Control Protocol/Internet Protocol (TCP/IP) networks corresponds to the IP layer. 
Data frames at the IP layer also include a header which contains an IP source address and 
an IP destination address. Routers or layer 3 switches may re-assemble or convert re- 
ceived data frames from one LAN standard (e.g., Ethernet) to another (e.g. token ring). 
Thus, layer 3 devices are often used to interconnect dissimilar subnetworks. 

15 Voice over IP (VoIP) 

Traditionally, computer networks were used to exchange static files or data, such 
as text and spreadsheet files, while the Public Switched Telephone Network (PSTN) was 
used to exchange voice information. Computer networks, however, are increasingly be- 
ing used to transport "voice" information. Voice over IP (VoIP) typically refers to a 

20 group of technologies used to transmit voice information over computer networks. Such 
networks include a plurality of voice agents that convert voice information from its tradi- 
tional telephony form to a form suitable for packet transmission. In other words, the 
voice agent encodes, compresses and encapsulates the voice information into a plurality 
of data packets. Examples of voice agents include IP telephones, VoIP gateways, certain 

25 private branch exchanges (PBXs), etc. A calling party uses a voice agent to initiate a 
VoIP call. Once the voice information has been converted into packet format, it is car- 
ried by the computer network to a second voice agent configured to serve the called 
party. Voice traffic, unlike static data files or records, is highly sensitive to delay and to 
lost packets. That is, delays in receiving data packets carrying voice information at the 

30 called party's voice agent can seriously degrade the quality of the call. Accordingly, 
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packets carrying voice information must be delivered to the called party with high prob- 
ability and in a timely manner. 

Computer networks include numerous services and resources for use in forward- 
ing network traffic. For example, different network links, such as Fast Ethernet, Asyn- 
chronous Transfer Mode (ATM) channels, SONET links, satellite links, etc., offer differ- 
ent speed and bandwidth capabilities. Particular intermediate devices also include spe- 
cific resources or services, such as priority queues, filter settings, traffic shapers, queue 
selection strategies, congestion control algorithms, etc. that affect the rate at which traffic 
moves through the device and thus across the network. Depending on the selection or 
allocation of such resources or services, network traffic for different sources and sinks 
can be forwarded at different speeds or rates, thereby controlling the loss and/or delay 
experienced by the traffic. 

The Resource Reservation Protocol 

As set forth above, to support VoIP, packets carrying voice information must 
typically be delivered within narrow time constraints. Although many computer net- 
works have the resources and services to meet the delivery requirements of VoIP, these 
resources and services must be allocated, preferably in advance, to the correct network 
traffic. The Resource reSerVation Protocol (RSVP), which is set forth at RFC 2205, is a 
signaling protocol that was developed so that entities (typically referred to as receivers) 
could reserve bandwidth within their computer networks to receive from one or more 
sourcing entities a desired traffic flow, such as multimedia stream. Pursuant to RSVP, 
sources send RSVP Path messages identifying themselves and indicating the bandwidth 
needed to receive their programming or content. These messages proceed hop-by-hop 
through the intermediate network devices, making those devices aware of the possibility 
that a reservation of resources may be required. If a receiver is interested in the pro- 
gramming or content offered by a particular source, it responds with a RSVP Reservation 
(Resv) message, which travels hop-by-hop back to the source. At each hop, the corre- 
sponding intermediate device establishes a session for the receiver and sets aside suffi- 
cient resources to provide the requested bandwidth for the desired traffic flow. These 
resources are immediately made available to the traffic flow. If the resources are not 
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available, the reservation is refused explicitly so that the receiver knows it cannot depend 
on the corresponding resources being devoted to its traffic. By using RSVP, packets car- 
rying voice information can be accorded the resources and services they need to ensure 
timely delivery. 

In voice applications, RSVP is typically utilized to reserve network resources be- 
fore the called party's phone begins ringing. Doing so has the advantage of not disturb- 
ing a called party when the resources to support acceptable voice quality are not avail- 
able. However, pre-reserving resources creates potential problems. For example, an at- 
tacker could make use of those reserved resources without ever causing the signal that 
starts the billing cycle to be sent, e.g., the picking up of the phone by the called party. 
The attacker can thus "consume" valuable network resources without ever having to pay 
or otherwise be accountable for them. In fact, the "attacker" can be one or both of the 
calling and/or the called party, opening up a particularly serious theft-of-service capabil- 
ity known as "toll fraud" in the legacy telecommunications sector. 

SUMMARY OF THE INVENTION 

Briefly, the invention relates to a two phase reservation mechanism for use with 
computer networks carrying voice or other time-sensitive or high bandwidth information. 
During the first phase, called the "resource allocation" phase, network resources suffi- 
cient to support the anticipated voice traffic are set aside within the computer network 
along the entire route between the calling party and called party. Although the network 
resources have been set aside, they are specifically not made available to the voice traffic 
for which they were reserved, until the second phase of the reservation mechanism, called 
the "resource available" phase. During the resource available phase, the network re- 
sources that were previously set aside are now made available for application to the voice 
traffic. In other words, it is only after the resource available phase that the allocated net- 
work resources can be utilized by the voice traffic. 

According to the illustrative embodiment, an intermediate network device along 
the route between the calling and the called parties includes a reservation engine, a packet 
classification engine, an admission control entity, and a traffic scheduler. The reservation 
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engine preferably operates in accordance with the Resource reSerVation Protocol (RSVP) 
specification standard and includes an RSVP message generator and an RSVP state ma- 
chine engine. To reserve network resources sufficient to carry the voice traffic between 
the calling and the called parties, one or more RSVP Path messages are sent across the 
computer network from the calling party to the called party. The Path messages follow a 
particular route through the computer network. In response to the Path messages, one or 
more first RSVP Resv messages are returned from the called party to the calling party 
following the inverse of the route taken by the Path messages. The first Resv messages 
specify the bandwidth that is being requested to support the voice traffic and a set of pa- 
rameters or "classification criteria" for use in identifying that traffic. The first Resv mes- 
sages also carry a two phase reservation flag, which is preferably asserted. 

The RSVP engine of the intermediate device is configured to examine the two 
phase reservation flag and, if it is asserted, to enter the resource allocation phase. In the 
resource allocation phase, the RSVP engine contacts the admission control entity to de- 
termine whether the reservation request represented by the Resv message should be ac- 
cepted or rejected. If the reservation request is accepted, the RSVP engine sets aside suf- 
ficient network resources to support the reservation request and directs the state machine 
to enter a resources allocated state for this reservation request. The RSVP engine does 
not, however, direct the traffic scheduler to apply these resources to the network traffic 
identified in the Resv message. Alternatively, the RSVP engine may direct the traffic 
scheduler to discard such packets or to give them poorer service than other traffic in order 
to discourage the transmission of network messages while in the resources allocated state 
which typically precedes the start of the billing cycle. 

Next, one or more second Resv messages are sent from the called party to the 
calling party. In the second Resv message, the two phase reservation flag is deasserted. 
Again, the RSVP engine of the intermediate device examines the two phase reservation 
flag of these Resv messages. In response to the flag being deasserted, the RSVP engine 
directs the state machine to transition from the resources allocated state to a resources 
available state. It is in this state that the RSVP engine directs the packet classifier and the 
traffic scheduler to look for and identify network traffic matching the criteria specified in 
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the Resv messages, and to make the allocated resources available to the network traffic 
matching those criteria. By separating the allocation of network resources into two 
phases, the present invention provides more precise control over the allocation and use of 
such references. Furthermore, resources are not actually made available for use until an 
appropriate point in the process, e.g., when the called party actually picks up the "phone". 
It also provides a more precise opportunity to start a corresponding billing cycle. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention description below refers to the accompanying drawings, of which: 
Fig. 1 is a highly schematic diagram of a computer network; 
Fig. 2 is a highly schematic block diagram of a voice agent in accordance with the 
present invention; 

Fig. 3 is a highly schematic block diagram of an intermediate network device in 
accordance with the present invention; 

Figs. 4A-C is a flow diagram of the preferred method of the present invention; 

Fig. 5 is a highly schematic diagram of a reservation message in accordance with 
the present invention; 

Fig. 6 is a state diagram in accordance with the present invention; and 

Fig. 7 is an event table in accordance with the present invention. 

DETAILED DESCRIPTION OF AN ILLUSTRATIVE 

EMBODIMENT 

Fig. 1 is a highly schematic diagram of a computer network 100. The network 
100 includes first and second voice agents 102, 104 that are interconnected by a plurality 
of intermediate network devices. More specifically, first voice agent 102 is coupled to a 
first hop network device, such as router 106, which, in turn, is coupled to a second net- 
work device, such as router 108. Router 108, in turn, is coupled to a network cloud 110. 
The network cloud 110 may consist of a plurality of network devices, local area networks 
(LANs), and end stations. Second voice agent 104 is similarly coupled to a first hop net- 
work device, such as router 112, which, in turn, is coupled to network cloud 110. 
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Fig. 2 is a highly schematic, partial block diagram of a voice agent, such as 
voice agent 102. Voice agent 102 preferably includes a communication facility 202 and 
one or more resource reservation components, such as a Resource reSerVation Protocol 
(RSVP) entity or engine 204. As described herein, the RSVP entity 204, which includes 
a RSVP message generator 206 and a RSVP state machine engine 208, operates, in part, 
in accordance with the RSVP specification standard, which is set forth at RFC 2205 and 
is hereby incorporated by reference in its entirety. Voice agent 102 further includes a 
call signaling entity 210 in communicating relationship with the RSVP entity 204 and 
communication facility 202. Entity 210 operates in accordance with a signaling proto- 
col, such as H.323, Session Initiation Protocol (SIP), Media Gateway Control Protocol 
(MGCP) or MEGACO, which is an extension of MGCP. The RSVP entity 204 is also 
in communicating relationship with the communication facility 202, and can thus ex- 
change information, including network packets and frames with facility 202. 

The communication facility 202 preferably includes one or more software li- 
braries for implementing a communication protocol stack allowing voice agent 102 to 
exchange messages with other entities of network 100, such as voice agent 104. The 
communication facility 202 may, for example, include software layers corresponding to 
the Transmission Control Protocol/Internet Protocol (TCP/IP), although other communi- 
cation protocols, such as Asynchronous Transfer Mode (ATM) cells, the Internet Packet 
Exchange (IPX) protocol, the AppleTalk protocol, the DECNet protocol and/or NetBIOS 
Extended User Interface (NetBEUI) could be utilized. Communication facility 202 fur- 
ther includes transmitting and receiving circuitry and components, including one or 
more network interface cards (NICs) that establish one or more physical ports for ex- 
changing data packets and frames with router 106 to which it is connected. 

In accordance with the preferred embodiment, voice agent 102 includes pro- 
grammable processing elements (not shown), which may contain software program in- 
structions pertaining to the methods of the present invention. Other computer readable 
media may also be used to store the program instructions. 
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Voice agents 102, 204 may be computer end stations, such as personal computers 
(PCs), running one or more communication applications that include RSVP support, such 
as Netmeeting from Microsoft Corp. of Redmond, Washington. Suitable computer plat- 
forms for use with the present invention are commercially available from Dell Computer 
Corp. of Round Rock, Texas, and Compaq Computer Corp. of Houston, Texas. 

Fig. 3 is a highly schematic, partial, functional block diagram of an intermediate 
network device in accordance with the present invention, such as router 106, which is the 
first hop router from voice agent 102. Router 106 preferably includes a packet/frame re- 
ceiver transmitter object 302, a traffic scheduler 304, and a forwarding engine 305. The 
traffic scheduler 304 includes a plurality of resources or services that are used by router 
106 to forward packets. For example, scheduler 304 may include one or more metering 
entities 306, one or more marker entities 308, one or more shaper entities 309, one or 
more dropper entities 310, and one or more queue selector entities 312. The queue se- 
lector entity 312, moreover, includes or has access to a plurality of queues 314a-d which 
buffer packets for the interfaces and/or ports that have been configured at router 106. 
The packet/frame receiver transmitter object 302 is configured as one or more interfaces 
or ports for receiving and sending network messages for router 106. The packet/frame 
receiver transmitter object 302, the traffic scheduler 304, and forwarding engine 305 are 
in communicating relationship with each other via one or more bus structures, such as 
system bus 315, so that network messages as well as commands may be exchanged be- 
tween them. 

Router 106 further includes one or more resource allocation and reservation com- 
ponents. In the preferred embodiment, router 108 includes a RSVP entity or engine 316, 
a packet/frame classification engine 318, and an admission control entity 320. The RSVP 
engine 316, moreover, includes an RSVP message generator 322 and an RSVP state ma- 
chine engine 324, and also operates, in part, in accordance with the RFC 2205 specifica- 
tion standard. Router 106 also includes programmable processing elements (not shown), 
which may contain software program instructions pertaining to the methods of the pres- 
ent invention. Other computer readable media may also be used to store the program 
instructions. 
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A suitable platform for router 106 is the 7200 or 4700 series of routers from Cisco 
Systems, Inc. of San Jose, California. Nonetheless, those skilled in the art will recognize 
that the present invention, or parts thereof, may be implemented in other network devices 
and/or entities. 

Figs. 4A-C is a flow diagram of the method of the present invention. Suppose, for 
example, that a calling party utilizes voice agent 104 to place a call to a called party at 
voice agent 102. The calling party may enter a series of numbers at voice agent 104 that 
identify voice agent 102. To insure that the anticipated voice traffic from voice agent 104 
is forwarded through the computer network 100 in a timely manner, i.e., with minimal 
delay, voice agent 104 (in cooperation with agent 102 as described below) preferably 
causes sufficient resources to be reserved across the network 100 to meet the time con- 
straints of voice traffic. Specifically, the RSVP message generator 206 of RSVP entity 
204 at voice agent 102 formulates one or more RSVP Path messages, as indicated at 
block 402 (Fig. 4 A). The signaling entity 210 may initiate this process by issuing an Ap- 
plication Programming Interface (API) system call to RSVP entity 204 directing it to al- 
locate resources to the call. 

As provided in the RSVP specification standard, each RSVP Path message in- 
cludes a header, a sender template object, and a sender Tspec object, each of which com- 
prises a plurality of fields. The sender template object specifies the Internet Protocol (IP) 
address and Transmission Control Protocol/User Datagram Protocol (TCP/UDP) source 
port of the sending entity, i.e., voice agent 104. The sender Tspec object describes char- 
acteristics of the traffic to be generated by the sending entity, including the bandwidth 
required to support its delivery. 

The Path message is then passed to the voice agent's communication facility 202 
for transmission toward voice agent 102 via network 100, as indicated at block 404. The 
Path message is first received at router 112, which consults a routing table (not shown) to 
determine the next hop for the Path message. At each hop along the route to voice agent 
102, including router 1 12, the respective intermediate network device processes the Path 
message, as indicated at block 406. In particular, the device establishes path state based 
on the contents of the message, and records the IP address of the upstream device, as also 
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indicated at block 406. Each intermediate device also loads its IP address into a previous 
hop object that it adds to the Path message before forwarding it to the next intermediate 
network device along the route. Thus, when the Path message reaches its destination 
(e.g., voice agent 102), each intermediate network device along the route from the 
sourcing entity will have stored the address of the previous hop along the route so that it 
is able to forward messages back to the sourcing entity along the same route, but in the 
opposite direction. Voice agent 102 preferably responds to the Path message by generat- 
ing one or more first RSVP Reservation (Resv) messages, as indicated at block 408. 

Fig. 5 is a schematic block diagram of a Resv message 500. The Resv message 
500 includes a header 502, a filter spec object 504 and a flowspec object 506 each of 
which have a plurality of fields. In particular, the header 502 has a version field 508, a 
flags field 510, a message type field 512, an RSVP checksum field 514, a Send Time To 
Live (TTL) field 516, a reserved field 518 and an RSVP length field 520. Header fields 
508, 512-516 and 520 are preferably loaded in a conventional manner. The filter spec 
object 504 has a length field 522 (loaded with the length of the respective object), a class 
number field (C-Num) 524 and a class type (C-type) field 526. It further includes an IP 
source address (SA) field 528, a source port number field 530 and may include one or 
more un-used fields. The RSVP message generator 206 at voice agent 102 loads the IP 
SA and source port fields 528, 530 with the IP address and TCP/UDP port of voice agent 
104. 

The flowspec object 506 also includes length 532, class number 534 and class 
type 536 fields. It further includes a token bucket rate field 538, a token bucket size field 
540, a peak data rate field 542, a minimum policed unit field 544 and a maximum packet 
size field 546, among others. The RSVP message generator 206 loads fields 538-546 
with values corresponding to the network resources, e.g., the bandwidth, that voice agent 
102 requests to be reserved to support the anticipated voice traffic from voice agent 104. 
Typically, this bandwidth will be the same as that specified in the Path message. 

Resv message 500 may include other objects, such as a session spec object that 
carries the IP address and TCP/UDP port number utilized by voice agent 102 to receive 
the traffic flow from voice agent 104. 
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In accordance with the present invention, the flags field 510 of the Resv header 
502 is configured to include a 1-bit "two phase reservation" flag 548 (shown in hatch 
format), as also indicated at block 408. Voice agent 102 preferably asserts flag 548, as 
indicated at block 410. The first Resv message 400 travels hop-by-hop back to the 
source, e.g., voice agent 104, following the inverse of the route taken by the Path mes- 
sage. At each intermediate network device along the route, the first Resv message 500 is 
processed and a reservation state is established. In accordance with the present invention, 
there are at least two possible reservation states. 

Figs. 6 and 7 illustrate a state diagram 600 and an event table 700, respectively, in 
accordance with the present invention. As shown at Fig. 6, the two reservation states in- 
clude: a resources allocated state 602, and a resources available state 604. As described 
below, a given reservation enters, transitions between and leaves these states in response 
to a plurality of events. 

The first Resv message 500 is initially received at router 106. The packet/frame 
receiver transmitter object 302 of router 106 recognizes the received message as a Resv 
message and, accordingly, passes it to the RSVP engine 3 16 for processing, as indicated 
at block 412 (Fig. 4B). The RSVP engine 316 first examines the two phase reservation 
flag 548 of the received Resv message 500. In other words, the RSVP engine 316 deter- 
mines whether the two phase reservation flag 548 is asserted or deasserted, as indicated at 
decision block 414. If the two phase reservation flag 588 is asserted, the RSVP engine 
316 next performs admission control on the reservation request, as indicated by decision 
block 416. More specifically, using the contents of the flowspec spec object 506, the 
RSVP engine 316, queries the admission control entity 320 to determine whether router 
106 has sufficient available resources to support the requested reservation. RSVP engine 
316 may also determine whether or not the party making the reservation e.g., voice agent 
102, has administrative permission to make the reservation specified in the RSVP Resv 
message 500. 

Assuming the reservation represented by the Resv message 500 passes admission 
control, the RSVP engine 316 places the reservation in the resources allocated state 602, 
as indicated at block 318. That is, if the two phase reservation flag 548 of the Resv mes- 
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sage 500 is asserted, and the reservation passes admission control at the respective de- 
vice, the reservation enters the resources allocated state. This corresponds to event El 
702 (Fig. 7). The intermediate device then forwards the Resv message 500 to the next 
hop toward the sourcing entity, i.e., voice agent 104, as indicated at block 430. Accord- 
ingly, this process is preferably repeated at each intermediate device along the route from 
voice agent 104 to voice agent 102. That is, each network device along the route places 
the reservation in the resources allocated state 602 in response to the first Resv message 
500. 

Significantly, although network resources have been allocated at each of these 
intermediate devices, those resources are not yet made available to the voice traffic from 
voice agent 104, as indicated by block 418. Should voice agent 104 begin sending voice 
traffic to voice agent 102, the intermediate network devices will not utilize the allocated 
resources for this traffic because the reservation is still in the resources allocated state 
602. Instead, the voice traffic will be forwarded pursuant to the intermediate network 
devices' "best efforts". Alternatively, the voice traffic may be discarded or given differ- 
entially poorer service by the intermediate devices. Nonetheless, because the resources 
have been allocated to the anticipated traffic flow from voice agent 104, they are not con- 
sidered to be available in response to other reservation requests that may be received by 
the intermediate devices. Thus, subsequent reservation requests may fail admission con- 
trol. 

If in response to decision block 416, the reservation fails admission control, the 
RSVP message generator 322 formulates a reservation error (ResvErr) message and 
sends it back toward the destination/receiving entity, i.e., voice agent 102, as indicated at 
block 422. The receiving entity is thus informed that the requested reservation failed. 

Assuming the reservation passes admission control at each node, when the called 
party answers the phone, or some other predefined action or event takes place, the previ- 
ously allocated resources are then made available to the voice traffic. More specifically, 
in response to the called party accepting the call, i.e., interacting the with VoIP applica- 
tion, in this example NetMeeting, or, in the case of a VoIP phone, removing the handset 
from its cradle, voice agent 102 generates a second Resv message, as indicated at block 
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424. Again, call signaling entity 210 may initiate this process by issuing an API system 
call directing RSVP entity 204 of voice agent 102 to make the allocated resources avail- 
able to the call. In the second Resv message 500, the RSVP entity 204 deasserts the two 
phase reservation flag 548, as indicated at block 426, which in all other respects is identi- 
cal the first Resv message(s). The second Resv message 500 is similarly passed to com- 
munication engine 202 from where it is transmitted onto network 100 and forwarded hop- 
by-hop toward the sourcing entity, i.e., voice agent 104, as also indicted at block 426. At 
each intermediate device, such as router 106, the second Resv message is captured by the 
packet/frame receiver transmitter object 302 and passed to the RSVP engine 316, as indi- 
cated at block 412. 

Again, the RSVP engine 316 determines whether the two phase reservation flag 
548 is asserted, as indicated at decision block 414. In this case, the flag 548 is deas- 
serted. Accordingly, processing jumps to block 428 (Fig. 4C), where the RSVP engine 
316 matches the second Resv message with reservation state established in response to 
the first Resv message. The RSVP engine 3 1 6 next directs the RSVP state machine en- 
gine 324 to transition the corresponding reservation state from the resources allocated 
state 602 to the resources available state 604, as indicated at block 430. The receipt of a 
Resv message 500 with the two phase reservation flag 548 deasserted corresponds to 
event E2 704 (Fig. 7). The RSVP engine 316 then instructs the packet/frame classifica- 
tion engine 318 to identify received traffic, i.e., packets, matching the classification crite- 
ria contained in the Resv message 500, such as the filter spec and session spec objects, as 
indicated at block 432, and directs the traffic scheduler 304 to apply the previously allo- 
cated resources to received traffic matching that criteria, as indicated at block 434. In 
other words, it is at this point that the RSVP engine 316 makes the previously allocated 
resources available for application to the traffic flow from voice agent 104. The receipt 
of a Resv message with the flag 548 deasserted may be interpreted by one or more of the 
intermediate network devices as a signal to start billing for the resources. 

Router 106 then forwards the second RSVP Resv message 500 to the next hop 
toward voice agent 104, as indicated at block 436. This processing of the second Resv 
message is thus preferably repeated at each intermediate network device along the route 
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to voice agent 104. Thereafter, the traffic flow from agent 104 to agent 102 is provided 
with sufficient resources to ensure timely, high quality delivery. As shown, with the pre- 
sent invention, the two phase reservation mechanism is preferably applied at each net- 
work device along the entire route between voice agents 102, 104, thereby providing end- 
to-end, two phase resource reservation. 

When a reservation enters the resources allocated state 602, the state machine en- 
gine 324 may activate a timer or counter. If the reservation is still in the resources allo- 
cated state 602 after expiration of some preset time as determined by the timer or counter, 
the RSVP engine 316 may delete or teardown the reservation. That is, if a second Resv 
message with a deasserted two phase reservation flag 548 is not received within a prede- 
termined time-out period, the reservation is discarded. This responds to event E3 706 
(Fig. 7). 

To maintain the reservation in the resources available state 604, voice agent 102 
may periodically issue Resv messages 500 with the two phase reservation flag 548 deas- 
serted, to refresh that state. In particular, when the reservation first transitions to the re- 
sources available state 604 (as well as each time that state is refreshed), a timer or counter 
may be initialized by the RSVP engine 316. If this counter or timer reaches a predeter- 
mined value prior to a subsequent Resv message being received (with the flag 548 deas- 
serted), the reservation may be discarded, thereby releasing the previously allocated and 
available resources for assignment to another reservation. This corresponds to event E4 
708 (Fig. 7). 

A reservation in either the resources allocated or in the resources available states 
602, 604 may also be discarded in response to a RSVP reservation teardown (ResvTear) 
message being received. ResvTear messages are typically issued by a receiving entity, 
e.g., voice agent 102, after the traffic flow for which the reservation was created is com- 
plete. The receipt of ResvTear messages corresponds to events E5 710 and E6 712 (Fig. 
7). 

Intermediate network devices that have not been configured to recognize a two 
phase reservation flag 548 preferably process the corresponding Resv message in a con- 
ventional manner, ignoring the value of flag 548. That is, these "legacy" devices perform 
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admission control and reserve resources (and make them immediately available) in re- 
sponse to a first Resv message in which the two phase reservation flag is asserted. A 
second Resv message whose two phase reservation flag is deasserted will result the pre- 
viously established reservation being refreshed. Thus, the present invention provides 
backwards compatibility. 

Additionally, a voice agent could be configured in some situations to deassert the 
two phase reservation flag 548 in the first Resv message issued by the agent. An inter- 
mediate device receiving a first Resv message in which flag 548 is deasserted preferably 
performs admission control on the Resv message and, if the reservation request passes 
admission control, the device preferably makes the requested resources available to the 
specified traffic flow immediately. 

Those skilled in the art will recognize that various modifications can be made to 
the present invention and still achieve its objectives. 

For example, those skilled in the art will understand that the 1-bit two phase res- 
ervation flag 548 could alternatively be disposed in other locations of the Resv message. 
For example, it could be located in the reserved area 518 of the header 502, some other 
header field, or in one of the objects appended to the Resv message 500. A separate 
RSVP object could even be defined for carrying the two phase reservation flag 548. 

It should further be understood that the present invention can be used with other 
reservation or signaling protocols besides RSVP. For example, the present invention can 
be advantageously used with ATM signaling protocols, such as Q.2931. 

It should also be understood that a reservation of network resources preferably 
occurs from voice agent 102 to voice agent 104 to support the voice traffic flowing in this 
direction as well. This reservation process preferably occurs in the same manner as de- 
scribed above. 

Other suitable voice agents include VoIP or Internet Telephones having RSVP 
support. Furthermore, a voice agent could be "built-in" an intermediate network device, 
such the 3600 series of routers with VoIP gateway support from Cisco Systems, Inc., 
which are configured to receive signals directly from a conventional analog telephone set. 
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In this case, the intermediate network device would include a RSVP entity configured to 
insert a two phase reservation flag 548 into Resv messages generated by the device on 
behalf of the analog telephone set, and to assert/deassert that flag as described herein. A 
first hop intermediate network device may also be configured to act as a RSVP proxy for 
a corresponding VoIP telephone coupled to the device. In this case, the device would 
again include a RSVP entity configured to insert a two phase reservation flag into Resv 
messages generated on behalf of the VoIP telephone, and to assert/deassert that flag. 

Also, it should be understood that the voice traffic described herein may be ex- 
changed between multimedia terminal adapters coupled to cable modems, which, in turn, 
are connected to a cable network. In this case, the corresponding cable modem termina- 
tion systems (CMTSs) would generate the first and second Resv messages carrying flag 
548. 

The foregoing description has been directed to specific embodiments of this in- 
vention. It will be apparent, however, that other variations and modifications may be 
made to the described embodiments, with the attainment of some or all of their advan- 
tages. For example, the present invention can be used with other time-sensitive or high 
bandwidth traffic flows besides voice, such as video or multimedia traffic flows. There- 
fore, it is an object of the appended claims to cover all such variations and modifications 
as come within the true spirit and scope of the invention. 

What is claimed is: 
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